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I. Real Party in Interest 

Sun Microsystems, Inc. 
4120 Network Circle 
Santa Clara, CA 95054 
USA 

II. Related Appeals and Interferences 

No other appeals or interferences are currently known to Appellants that will 
directly affect, be directly affected by, or have a bearing on the decision to be rendered by 
the Board of Patent Appeals and Interferences in the present appeal. 
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III. Status of Claims 

Claims 1-18 are pending in the application. No claims have been allowed. 



Claims 7-12 were rejected under 35 U.S.C. 103 based upon 35 U.S.C. § 1 12, 
second paragraph as being indefinite for failing to particularly point out and distinctly 
claim the subject matter which the Applicants regard as the invention. 

Claims 1-2, 5-8, 1 1-14, and 17-18 were rejected under 35 U.S.C. § 102 as being 
anticipated by U.S. Patent No. 6,349,340 by Dyer et al. ("Dyer"). 

Claim 3-4, 9-10 and 15-16 were rejected under 35 U.S.C. § 103 based upon Dyer 
and further in view of U.S. Patent Application Publication No. 2002/0065929 by 
Kamentsky et al ("Kamentsky"). 

IV. Status of Amendments 

All the claim amendments have been entered. No amendments have been filed 
in response to the Final Office Action mailed on September 22, 2005. 

V. Summary of Claimed Subject Matter 

Claims 1, 7, and 13 are at issue in this Appeal. The following concise explanation 
of the subject matter defined in each of the independent claims 1, 7, and 13 involved in 
this Appeal refer to the specification by page and line numbers, and to the drawing by 
reference characters. 

The method of communicating in a remote services system of claim 1 is clearly 
shown in Figure 1 1 and Figures 20-23B and is described at paragraph [0112] and 
paragraphs [0208-0217]. As shown in Figure 11, communication within the remote 
service architecture includes three tiers, a remote services proxy tier 1 1 10, an 
intermediate Mid Level Manager (MLM) tier 1112, and an application ML Mans server 
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tier 1114. Communication is established and connections are made from the bottom tier 
(the remote proxy tier) to the top tier. 

As discussed beginning at paragraph [021 1] bulk data transfer, a multicast, is 
generally started by the applications MLM 218. The remote services system 100 
proceeds by fetching the data to be multicast to the nearest intermediate MLM 216 which 
is then responsible for redistributing the data to the final destinations (i.e. the 
intermediate MLM 216 performs the multicast). More specifically, the applications 
MLM allocates a URL to store and publish the bulk data to be transferred 2210 at step 
2212 using a web server 2214. The applications MLM 218 then creates a transfer request 
and sends the request via the back-channel at step 2216. The short message 2220 
requesting the transfer includes the data transfer request, the data size, the URL location 
for obtaining the data. 

The intermediate MLM 216 can then determine whether to accept the transfer. If 
accepted, the intermediate MLM 216 fetches the file and publishes the file at step 2240. 
Figures 23A and 23B show the fetch operation in more detail. 

The method of claim 7 and system of claim 13 also multicast in the same manner 
as described above. Paragraphs [0050] and [0095] describe how the remote services 
proxy 210 also manages allocation of remote services identifiers (ID's), which are 
allocated to each component of the remote services infrastructure, and the support 
instances that are registered with the remote services system 100. 

The remote services proxy ID management module 514 manages the allocation of 
unique identifiers for the proxy 210 itself and any support instances that are registered 
through an Application Program Interface ("API"). The remote services system 100 
relies on the creation of unique ID's to manage individual support instances. This 
function is provided within the proxy 210 because there is no unique cross platform 
identifier available within the remote services system 100. The proxy 210 manages the 
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mapping between the systems management ID (e.g., IP address) and the remote services 
ID, which is keyed off the unique customer ID provided at installation time within the 
deployed system. 

VI. Grounds of Rejection to be Reviewed on Appeal 

Claims 1, 7 and 13 were rejected under 35 U.S.C. § 102 as being anticipated by 

Dyer. 
VII. Argument 

Rejection of claims 1, 7 and 13 based upon Dyer under 35 U.S.C. §102 is 
improper since Dyer fails to disclose each and every aspect of the claimed invention. 

The Examiner's rejections of claims 1, 7, and 13 of the Appellants' invention is 
improper since Dyer fails to disclose the establishment of a back-channel 
communications path only after a forward channel communication path is established. 

Claim 1 states: 

1. A method of communicating in a remote services system comprising: 
communicating a forward channel communication using a forward channel 

communication path; 
communicating a back-channel communication using a back-channel communication 
path, the back-channel communication path being established only after a 
forward channel communication path is established; and, 

using the back-channel communication path to multicast a message to a group of 
remote service components. 



\\\CS - ;eC:t6/0 J046: - d-!"^ V: 



4 



Claim 7 states: 

7. A method of communicating in a remote services system comprising: 

assigning a plurality of remote service components within the remote services system 
with a respective plurality of unique remote services identifiers; 

communicating a forward channel communication using a forward channel 
communication path; 

communicating a back-channel communication using a back-channel communication 
path; and, 

using the back-channel communication path to multicast a message to a group of 
remote services components based upon unique remote services identifiers 
corresponding to components of the group of remote service components. 

Claim 13 states: 

13. A remote services system comprising: 

a plurality of remote service components, the plurality of remote service components 

including a respective plurality of unique remote services identifiers; 
a forward channel communication path coupled to the plurality of remote service 

components; 

a back-channel communications path coupled to the plurality of remote service 

components, the back-channel communications path allowing multicast of a 
message to a group of components based upon unique remote services 
identifiers corresponding to components of the group of remote service 
components. 
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The Examiner's logic in constructing a prima facie case of anticipation under 
Dyer is fundamentally flawed. The Examiner correlates citations in Dyer to the first and 
second elements of the claimed invention, namely the forward channel communication 
path and the establishment of the back-channel communication path, but then ignores that 
composition and improperly equates Dyer's distribution of multicast data to the back- 
channel communications path. According to the Examiner's construction, Dyer uses the 
forward channel communication path to distribute multicast data. The Examiner 
correlates the Appellants' forward channel communication path to the channel upon 
which the processes or nodes make their request for data and correlates the Appellants' 
use of the back-channel to the source channel upon which the multicast data is received 
from the source. Then, in making his rejection, the Examiner attempts to argue that the 
Appellants' claimed use of the back-channel to multicast data is the same as the 
subscribed client channels as discussed in Dyer. These channels, however, as is shown 
below, are the same channels that the Examiner identified as the channels from which the 
processes make their request for data, namely the forward channel communication path. 
The rejection is therefore improper. 

Dyer appears to teach a method for receiving requested multicast data over a 
plurality of multicast communication channels. Rather than transmitting a plurality of 
requested multicast data from a plurality of data sources to each of the requesting nodes, 
Dyer discloses a method to filter the multicast data and route the filtered data to the 
requesting processes so as to reduce network overloading. See Dyer abstract. Dyer 
establishes a channel communications path, or a source channel for multicast data as it is 
referenced in Dyer, after it receives a request for multicast data from a plurality of client 
nodes. Once the requests are received, a source communications path is established to 
convey the requested multicast data to a data distribution manager and one or more data 
distribution libraries. Thereafter, the data is communicated to the requesting nodes or 
services via the channel used to request the data. As recited in Dyer, "The method can 
include receiving from a process in a client node a request for multicast data; identifying 
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a source for the requested multicast data; determining a source communications channel 
for receiving the requested multicast data; enabling the source communication channel; 
receiving the multicast data through the source communications channel; and, forwarding 
the multicast data to the requesting client node process . Dyer Col. 2, lines 30-41 
(emphasis added). Significantly, the channel used to forward the multicast data appears 
to be the same channel upon which the request arrived. See Dyer Col. 3, lines 43-45, 49, 
Col. 6, lines 64-65. 

The Appellants' invention as claimed, utilizes the back-channel communications 
path to multicast data to a group of remote service components, not the forward channel 
as disclosed by Dyer and as construed by the Examiner. Using the Appellants' 
nomenclature according to the teachings of Dyer and as cited by the Examiner in brackets 
[ ], Dyer teaches "receiving from a process [using a forward channel communication 
path] a request for multicast data; identifying a source for the requested multicast data; 
determining a source communications channel [a back-channel communications path . . . 
established only after a forward channel communications path is established] for 
receiving the requested multicast data; enabling the source communications channel [the 
back-channel communication path]; receiving the requested multicast data through the 
source [back-channel communication path] communications channel; and, forwarding the 
multicast data to the requesting client node process \ via the back-channel communication 
path ]" Id. Clearly, the Examiner's attempt to equate the forwarding of the multicast 
data to the Appellants' claimed back-channel communication path is improper. 

Unlike Dyer, the Appellants' invention establishes the path by which to distribute 
the multicast data only after the establishment of the "source" communications channel. 
Dyer establishes this channel upon receiving the request for multicast data or at some 
other point of subscription from the plurality of client nodes. To clearly show why Dyer 
fails to disclose each and every limitation of the Appellants' invention, consider a 
wording of claim 1 using the nomenclature of Dyer, as cited by the Examiner found in 
brackets [ ]. 
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Claim 1 states: 



Communicating a forward channel communication using a forward channel 
communication path [requested by processes distributed on client nodes; receiving 
from a plurality of processes in a client node requests from multicast data]; 

communicating a back-channel communication using a back-channel 
communications path, the back-channel communication path being established 
only after a forward channel communication path is established [determining a 
source communication channel for receiving the multicast data; enabling the 
source communications channel]; and 

using the back-channel communication path to multicast a message to a 
group of components [multicast data corresponding to the request by the 
requesting processes]. 

As construed by the Examiner, Dyer uses the forward channel, or the channel 
upon through which the requested for multicast data are received, to distribute the 
multicast data. The back-channel, as construed by the Examiner, is then established after 
receiving the request for multicast data. The Examiner's argument however then fails 
with respect to the communication of the multicast data via the back-channel path as 
claimed by the Appellants. Using the Examiner's construction and as clearly shown in 
Dyer, the distribution of the multicast data would have to occur via the source or front- 
channel communications path. Yet the Appellants' claim that the multicast message is 
conveyed via the back-channel communications path. The Examiner's claim 
construction is inconsistent and flawed. 

The Examiner fails to show that each and every claimed limitation is present in 
Dyer. Accordingly the rejection of claim 1 under 35 U.S.C. § 102 is improper. 

With respect to claims 7 and 13, the Appellants further define that the back- 
channel communication of a multicast message is based on unique remote service 



identifiers. The Appellants agree that Dyer teaches that an IP address or subscriber 
ID/information is evidence of a respective unique remote service identifier. However, 
Dyer, as discussed above, associates these identifiers with the forward channel, not the 
back-channel as is claimed by the Appellants. Again, the Examiner's claim construction 
is flawed making his rejection under 35 U.S.C. § 102 improper. 

As claims 2-6, 8-12 and 14-18 depend from claims 1, 7 and 13 respectively, the 
rejection of these claims under 35 U.S.C. § 102 or 35 U.S.C. § 103 is also without 
foundation. Based on the above remarks, Appellants request that the rejection of claims 
1, 7 and 13 be reversed. 

Conclusion 

In view of all of the above, claims 1-6 and 13-18 are believed to be allowable and 
the case in condition for allowance. Claims 7-12 are believed to be allowable upon the 
resolution of an informality due to an inconsistent using of the word "services." 
Appellants respectfully request that the Examiner's rejections based on 35 U.S.C. 102 be 
reversed for all pending claims. 




Respectfully submitted, 

y 




Michael C. Martensen, Reg. No. 46,901 
HOGAN & HARTSON LLP 
One Tabor Center 
1200 17 th Street, Suite 1500 
Denver, Colorado 80202 
Phone: (719) 448-5910 
Fax: (71 9) 448-5922 
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VIII. APPENDIX OF CLAIMS ON APPEAL 



1. A method of communicating in a remote services system comprising: 
communicating a forward channel communication using a forward channel 

communication path; 

communicating a back-channel communication using a back-channel communication 
path, the back-channel communication path being established only after a 
forward channel communication path is established; and 

using the back-channel communication path to multicast a message to a group of 
remote service components. 

2. The method of claim 1 wherein the message being multicast is an 
administrative control message. 

3. The method of claim 1 wherein the message being multicast is a bulk transfer 

request. 

4. The method of claim 1 wherein the message being multicast is a bulk data 
response. 

5. The method of claim 1 wherein the remote services system includes an 
intermediate mid level manager, the intermediate mid level manager performing the multicast. 

6. The method of claim 5 wherein the remote services system includes an 
applications mid level manager, the applications mid level manager sending a request to the 
intermediate mid level manager to perform the multicast. 

7. A method of communicating in a remote services system comprising: 

assigning a plurality of remote service components within the remote services system 

with a respective plurality of unique remote services identifiers; 
communicating a forward channel communication using a forward channel 
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communication path; 
communicating a back-channel communication using a back-channel communication 
path; and 

using the back-channel communication path to multicast a message to a group of 
remote service components based upon unique remote services identifiers 
corresponding to components of the group of remote service components. 

8. The method of claim 7 wherein the message being multicast is an 
administrative control message. 

9. The method of claim 7 wherein the message being multicast is a bulk transfer 

request. 

10. The method of claim 7 wherein the message being multicast is a bulk data 
response. 

11. The method of claim 7 wherein the remote services system includes an 
intermediate mid level manager, the intermediate mid level manager performing the multicast. 

12. The method of claim 1 1 wherein the remote services system includes an 
applications mid level manager, the applications mid level manager sending a request to the 
intermediate mid level manager to perform the multicast. 

13. A remote services system comprising: 

a plurality of remote service components, the plurality of remote service components 

including a respective plurality of unique remote services identifiers; 
a forward channel communication path coupled to the plurality of remote service 

components; 

a back-channel communications path coupled to the plurality of remote service 
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components, the back-channel communications path allowing multicast of a 
message to a group of components based upon unique remote services 
identifiers corresponding to components of the group of remote service 
components. 

14. The system of claim 1 3 wherein the message being multicast is an 
administrative control message. 

15. The system of claim 1 3 wherein the message being multicast is a bulk transfer 

request. 

16. The system of claim 1 3 wherein the message being multicast is a bulk data 
response. 

17. The system of claim 13 wherein the plurality of components includes an 
intermediate mid level manager, the intermediate mid level manager performing the multicast. 

18. The system of claim 1 7 wherein the plurality of remote service components 
includes an applications mid level manager, the applications mid level manager sending a 
request to the intermediate mid level manager to perform the multicast. 
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IX. EVIDENCE APPENDIX 

No copies of evidence are required with this Appeal Brief. Appellants have not 
relied upon any evidence submitted under 37 C.F.R. §§ 1.130, 1 . 1 3 1 , or 1 . 1 32. 



13 



X. RELATED PROCEEDINGS APPENDIX 

There are no copies of decisions rendered by a court or the Board to provide with 
this Appeal as there are no related proceedings. 
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